home *** CD-ROM | disk | FTP | other *** search
/ Amiga Tools 3 / Amiga Tools 3.iso / grafik / raytracing / rayshade-4.0.6.3 / amiga_readme next >
Text File  |  1994-09-15  |  8KB  |  160 lines
  1. This is a full Amiga port of rayshade version 4.0.6.3, which, in turn,
  2. is based on the sources of my previous Amiga port of rayshade, which
  3. contained in one place most of the bug fixes and enhancements that had
  4. been posted to the rayshade mailing list.
  5.  
  6. Here are a few of the features of this port:
  7.  
  8. * Utah RLE support.
  9. * Several RLE utilities.
  10. * CPP support.
  11. * Raypaint. (In color!)
  12. * -L switch to invoke the SAS/C preprocessor, if you have it. Slower than
  13.   GNU cpp, but can preprocess things like #include "huge_file", on which
  14.   cpp runs out of memory on the Amiga.
  15.  
  16. Older versions of the Amiga port included a memory allocation hack that
  17. enabled rayshade to allocate up to twice the amount of memory than with
  18. the standard memory allocator. This was based on the observation that
  19. rayshade never freed the memory it allocated. As various additions to
  20. rayshade have made this observation false, the hack has been removed.
  21. The code for the hack has been left in libextra/stupidmalloc.c as a
  22. historical curiosity.
  23.  
  24. INSTALLATION:
  25.  
  26. (All binaries are compiled for a 68020+68881. They should run on all
  27. higher processors, but they will definitely crash if you only have a
  28. 68000/68010 or if you don't have an FPU.)
  29.  
  30. 1. If you have gcc installed on your hard disk, just copy all the binaries,
  31.    except cpp, from the BIN directory to some place on your hard disk, and
  32.    you're all set. If you want to save images as IFF files from within the
  33.    getami previewer, copy LIBS/iff.library to the LIBS: directory. Make
  34.    sure that the cpp program from the gcc distribution is in your path.
  35.  
  36. 2. If you don't have gcc, in addition to the above step, copy the cpp
  37.    program as well, and copy LIBS/ixemul.library to the LIBS: directory.
  38.    Make sure that the cpp program is in your path when you run rayshade or
  39.    raypaint.
  40.  
  41. WHAT'S INCLUDED:
  42.  
  43. * The entire rayshade source tree, with the rayshade, raypaint, and
  44.   rsconvert binaries, documentation, and example scene files.
  45. * The source for the Utah Raster Toolkit library.
  46. * Several utilities from the Utah Raster Toolkit to manipulate RLE bitmaps,
  47. * A couple of format conversion programs from the Utah Raster Toolkit to
  48.   convert to and from RLE files.
  49. * The getami RLE file previewer.
  50. * The fbcat program from the FBM toolkit, that can convert between several
  51.   image formats, including RLE.
  52. * Documentation for the supporting programs, in the MAN directory.
  53. * Various surface and other parameter settings, collected from various
  54.   sources, in the RAYFILES directory. In it you will also find the RSdefs
  55.   package, with additional definitions for NTSC HAM mode.
  56.  
  57. RUNNING THE PROGRAMS:
  58.  
  59. Make sure ixemul.library is in the LIBS: directory.
  60.  
  61. Rayshade and raypaint require lots of stack. I would suggest starting
  62. with 50,000 bytes, increasing the stack if you start getting crashes.
  63. (Some scenes render fine with just 20,000 bytes of stack, while others
  64. need more. I routinely use 250,000-500,000 bytes, to play it safe, so I
  65. don't really know what the minimum safe value is. Yes, I know I'm
  66. overdoing it!)
  67.  
  68. Rayshade works fine with VMM, a virtual memory management program, and I
  69. assume it also works with other similar programs like GigaMem, so if you
  70. run out of memory, fire up a virtual memory management program and keep
  71. on raytracing!
  72.  
  73. Documentation for raypaint is in raypaint/README. Raypaint will render
  74. in color, unless you specify the -M option, in which case it will render
  75. in black and white. If you don't have a three button mouse, pressing
  76. both buttons at the same time will do the same thing.  If you're using a
  77. program like DMouse that sends the current window/screen to the back
  78. when both buttons are pressed, you can try to fool it by pressing the
  79. right mouse button first.
  80.  
  81. If you're rendering into NTSC screens, keep in mind the 1:1.1 aspect
  82. ratio of the pixels. For 320x200 or 320x400 screens, you can compensate
  83. using the fov command, with a ratio of horizontal/vertical equal to
  84. (320/200)/1.1=1.45454545, e.g "fov 65.45454545 45". For PAL screens the
  85. pixels are nearly square, so you can use a ratio of 320/256=1.25, e.g.
  86. "fov 56.25 45".
  87.  
  88. RECOMPILING:
  89.  
  90. 1. Copy INCLUDE/*.h to your include directory. Iff.h is only required for
  91.    recompiling getami, so you can skip copying that, especially if you
  92.    happen to have a newer version that 23.2.
  93. 2. Go to the STDERRFIX directory. Edit the Makefile to your satisfaction,
  94.    and type make. Copy the resulting stderrfix.o and rle_stderrfix.o files
  95.    to the GNU:Lib directory. These two files fix a problem with gcc, which
  96.    does not create separate handles for stdout and stderr. For them to work
  97.    properly, you must compile your main program using -Dmain=mymain. (This
  98.    is done by the Makefiles, so you needn't worry.) Newer versions of gcc
  99.    come with stderrfix.o in the GNU:lib directory, but you will still need
  100.    to install rle_stderrfix.o.
  101. 3. Go to the URT/lib directory. Edit Makefile.amiga to your satisfaction,
  102.    and attempt to run make to build librle.a. This may fail, as I've only
  103.    managed to use the Makefile with SAS's smake. If you can't use make,
  104.    just do a straightforward compilation to produce the files mentioned in
  105.    the "makelib" file, then execute the "ar" command contained therein. I
  106.    apologize for the inconvenience.
  107. 4. Go to the top level directory. Edit libextras/Makefile,
  108.    libshade/Makefile, libray/lib*/Makefile, rayshade/Makefile,
  109.    raypaint/Makefile, and etc/rsconvert/Makefile. Copy config.h.amiga to
  110.    config.h, have a look at it to see if you want to change anything, then
  111.    type "make -f Makefile.amiga" and go for a cup of coffee. After a while,
  112.    you'll find the new binaries in rayshade/rayshade, raypaint/raypaint,
  113.    and etc/rsconvert/rsconvert.
  114.  
  115. In most cases I have provided Makefiles for SAS/C as well. I believe all
  116. programs compile fine with that compiler. However, as I have not really
  117. tested them (especially raypaint), I cannot guarantee that they actually
  118. work.  (My SAS Makefiles refer to my LIB:unix.lib library.  This is
  119. mainly for alloca, which is required by the bison parser. Grab a copy
  120. from one of the numerous GNU utilities, or use malloc, instead.)
  121.  
  122. If you need to compile utilities from the Utah Raster Toolkit, you can
  123. ftp the source from cs.utah.edu. The only modifications I've made are in
  124. the library source (included in this archive). Once you've built the rle
  125. library, the utilities should compile as is. If you use gcc, make sure
  126. you compile with the '-Dmain=mymain' switch, and that you link with
  127. GNU:lib/rle_stderrfix.o or GNU:lib/stderrfix.o, depending on whether
  128. your program requires the rle library or not. If you use SAS/C, there is
  129. no need for the stderrfix hack.
  130.  
  131. The directory URT/AMIGA_EXTRAS contains the source to a couple of
  132. utilities that are not in the official URT distribution, so you might
  133. want to add them to the URT sources, if you get them. (I believe that an
  134. older version of getami is part of the latest URT distribution. Unless
  135. you want a version of getami that runs under AmigaDOS 1.3, you can
  136. safely throw it away, and use the newer version provided here.)
  137.  
  138. REPORTING PROBLEMS:
  139.  
  140. If you encounter any problems related to the port, as opposed to
  141. problems with rayshade, let me know where I goofed, and I'll try to
  142. help.
  143.  
  144. This archive was originally put together in an afternoon, after someone
  145. suggested that I should release my rayshade port which was more complete
  146. than the one that used to be available on aminet. All programs were
  147. compiled from scratch using gcc 2.5.8 or 2.6.0 (rayshade, raypaint,
  148. rsconvert), with options to produce code for a 68020 with a 68881
  149. coprocessor. I have been using 68040 versions of these programs happily
  150. for a couple of years, and 68020 versions for a couple of years before
  151. that, so I believe that you should not have any problems in using them.
  152. On the other hand, I cannot _guarantee_ that you won't encounter any
  153. problems with these programs, so it is up to you to decide whether to
  154. use them or not. In the event that running any of these programs causes
  155. a hardware failure, loss of data, or other damage, I bear no
  156. responsibility.
  157.  
  158. Kriton Kyrimis    (UUCP:     pythia!theseas!kriton!kyrimis)
  159.               (INTERNET: kyrimis@theseas.ntua.gr)
  160.